I've got a few commits elsewhere cleaning up the third party warnings, but I'm still working on trying to get the include dirs passed to clang cleaned up. That'll clean up another few hundred errors.

If anyone with knowledge about some of the remaining rpcs3 warnings (@elad335 @Nekotekina maybe?) and think of a way to resolve them, I can put those changes here too. The problem is that those instructions are wrapped in macros that disable them for missing instruction sets. However the macros are just left blank, generating a warning. For example, after the preprocessor is run, we get code like the following
const auto sa = (A, index);

which is just weird

I've gone ahead and implemented the changes to silence 3rd party code. I put in some PoC workarounds for the macro issues; these changes may or may not be okay.

Currently, the clang travis build produces no warnings of any kind. The log has gone from 8665 lines to 1220.

I still have more plans. Neko recently turned on extra warnings (-Wall) for gcc that was not turned on for clang. I plan to unify the flags between the 2 compilers, since they are mostly compatible. I will try to get as close to exact -Wall compliance as I can in future commits. Perhaps even -Wextra if enough gets done. Hopefully we can maintain this into the future.

The 3rdparty warning silence doesn't seem to work on MSVC (using CMake). Not only does it let errors through but it now also spams cl : Command line warning D9025 : overriding '/w' with '/W4' for every single compiled LLVM file and similar erros for some other 3rdparty stuff. My setup is a bit unusual though, I don't expect full support for it.

I can upload the whole compile output somewhere if you're interested in wading through it.

Also, did anyone test running games on this? Double clicking anything on the game list causes a fatal error to pop up. Happens on both appveyor builds and the stuff I compiled myself.

Indeed, I did not add all the warning wrappers to msvc, just the one. msvc is at the bottom of my priority list right now, since I can barely read the output and my branch is on linux.
s crashing I think it may be inn regards to the shader strings being modified (only thing i can think of. I wont be able to update this pr for a few days, but Ill take a look at it when I get the chance.
In regards to the game

I've pushed an update with quite a bit of changes to what's going on. When adding -Wall to the compilers, many more warnings were exposed. It was both too many for me to handle, and also well outside my knowledge to fix. So while refactoring the cmake setup to be (hopefully) more clear than it was before, I decided to simply enumerate all the warnings as silenced, rather than not use -Wall.

This may seem odd (and that list is disturbingly long), but it provides a number of advantages. For one, the sight of it may encourage devs to begin working on them. For another, the log output is much cleaner, meaning that new PRs will have new warnings immediately highlighted for all to see, preventing issues from creeping in.

It also provides a neat little way for contributors to help the issue, as this is larger than one dev can handle. Simply pop a warning off the silenced list, repair the necessary code until it is fixed, then open a PR. Recently several PRs were introduced that had small warning-fix scope, and hopefully we can get more of those.

I still have plans here.

1. GCC has an old issue rearing its head, Linux: not used because `__STDC_CONSTANT_MACROS' is defined [-Winvalid-pch] #1818. It seems to have come back either in recent GCCs, or because I'm an idiot, or both. Before there was a warning silence in place (-Wno-invalid-pch), but readding this doesn't seem to help, likely because it is simply in the wrong place. It might be easier to fix than it looks, so I will look into that first.
2. MSVC has not been worked on at all, and I will have to do that. I have a wild fantasy that we might switch the windows build to clang and I won't have to do any work, but I cannot rely on that, given the "inertia" of the project.
3. Find a way to slap on -Werror. This will be useful as new PRs will clearly have warnings marked by CI, and it can't slip past reviewers who might be focused elsewhere.

And of course, I will be addressing the other review comments.

Also, my changes obviate #4989, so when this is done that can be closed.

Please rebase and resolve current reviews, other warnings can be cleaned up in a follow-up PR
This needs to be merged before hcorion's 16.04 PR

Squashed & rebased. Clang is clean, but GCC has problems with PCH still. That may be why GCC takes so much longer to build. I tried to look into it, but I get a different error than what is seen on travis. Someone with knowledge of cotire needs to take a look. Also, GCC is giving "notes", which seemingly can't be turned off, as they aren't even warnings. The changes required to fix the note spam is best handled by someone with knowledge of the objects.

Anyway, I think this is ready for merge, barring last minute review. The work on MSVC can be done separately.

Cancelled current build due to big queue, rebase after latest Nekotekina hotfix is merged for a new build, saves compiling time

Travis seems quiet. Is it ok to push?